<!DOCTYPE html PUBLIC "-//w3c//dtd html 4.0 transitional//en">
<html>
<head>
  <meta http-equiv="Content-Type"
 content="text/html; charset=iso-8859-1">
  <meta name="Author" content="Venkita Subramonian">
  <meta name="GENERATOR"
 content="Mozilla/4.76 [en] (Windows NT 5.0; U) [Netscape]">
  <title>CIAO Static Configuration</title>
  <base target="main"><!-- $Id$ -->
</head>
<body>
<center>
<h2>CIAO Static Configuration Support for Real-Time Platforms</h2>
</center>
<h3>
<a name="intro"></a>1. Introduction</h3>
The dynamic packaging, assembly, and deployment mechanisms currently
available
in CIAO are useful for application domains where component metadata is
less likely to be known a priori, where implementation upgrades may
need
to be performed on-line, and where platform features like loading and
unloading
dynamic libraries are both available and useful.&nbsp; Furthermore, the
new CCM Deployment and Configuration specification describes a wider
range
of configuration capabilities, opening up the question of alternative
component
configuration strategies more generally and requiring that any solution
we devise can be migrated to that new configuration approach.
<p>Therefore, we have incorporated support for component configuration
in CIAO on platforms like VxWorks, as a set of optional strategies and
optimizations to the existing CIAO configuration capabilities.&nbsp; By
supporting both dynamic and static styles of configuration in CIAO, we
will both (1) be able to realize our short term goals in making CIAO
available
on VxWorks for use in the Boeing PCES/MoBIES OEP, and (2) set a
precedent
for availability of static configuration capabilities more generally,
so
that DRE systems are well-supported within the new Deployment and
Configuration
specification implementation for CIAO as well.
</p>
<p>The fundamental intuition in understanding our approach is that in
DRE
systems the stages of the overall system lifecycle are similar to those
in more dynamic conventional component-oriented client-server
applications.&nbsp;
However, in DRE systems several phases of the system lifecycle are
compressed
into the compile-time and system-initialization phases, so that (1) for
testing and verification purposes the set of components in an
application
can be identified and analyzed before run-time, and (2) overheads for
run-time
operation following initialization are reduced and made more
predictable.
Furthermore, due to the nuances of the platforms traditionally used for
deploying DRE systems, not all features of conventional platforms are
available.
Our approach therefore avoids certain mechanisms that are either
unavailable
or too costly in terms of performance.
</p>
<p>We follow these intuitions in our approach, taking the existing
configuration
phases in CIAO and pushing several of them earlier in the configuration
lifecycle.&nbsp; We ensure that our approach can be realized in the
context
of the platforms on which the Boeing PCES/MoBIES OEP will be deployed,
notably VxWorks, by re-factoring the configuration mechanisms and
retargeting
them to use only the services available on the target real-time
platforms.
<br>
&nbsp;
</p>
<h3><a name="currentarch"></a>2. Current CIAO Configuration Architecture</h3>
<center>
<p><br>
<img src="imgs/ciao-dynamic1.jpg" height="462" width="774"></p>
<p><b>Figure 1. Current configuration process in CIAO</b></p>
</center>
<p>The first stage of the CIAO system lifecycle occurs off-line, when
component
package (.csd) and assembly (.cad) files are generated by a modeling
tool
or other prior stage of the tool chain.&nbsp; These files contain an
abstract
specification of the configuration that is to be achieved by CIAO in
each
particular deployment environment .
</p>
<p>CIAO interprets these .csd and .cad files, and creates and
configures
the components, their run-time server environments, and QoS properties
within the supporting ORB and other related infrastructure.&nbsp;
Currently,
CIAO runs several daemon processes for each deployment environment: one
or more Component Installation / Server Activation (CISA) daemons on
each
machine where components can be deployed, an additional Assembly
Manager
daemon and an Assembly Deployer process used by the system developer.
</p>
<p>The Assembly Manager stores an internal table with the target
platform
availability information .&nbsp;&nbsp;&nbsp; The Assembly Deployer
tells
the Assembly Manager which assemblies of components (each assembly is
defined
in a separate .cad file) should be deployed on which target
machines.&nbsp;
The Assembly Manager parses the XML structures in the .cad file, and
generates
its own internal data structure (<b>Figure 2</b>) as an intermediate
representation
of that assembly.
</p>
<p>The Assembly Manager then traverses (<b>Figure 2</b>) this
intermediate
representation, instructing each CISA daemon to install and configure
specific
component servers and containers, to create specific homes, and to
instantiate
specific component instances.&nbsp;&nbsp;&nbsp; Each CISA daemon has
additional
information about the component implementations available on that
endsystem
&#8211; each component UUID is mapped to a disk path for the .dll or .so file
within which a factory method for its home factory is defined.
</p>
<center>
<p><img src="imgs/ciao-dynamic2.jpg" height="384" width="699"></p>
<p><b>Figure 2. Intermediate representation of configuration information</b></p>
</center>
<p>The following steps are optional, and will only be performed if they
are explicitly specified in the assembly definition itself.&nbsp; For
the
sake of discussion, we consider the case where all the steps are in
fact
specified.&nbsp; The Assembly Manager will tell the CISA daemon the
UUIDs
of the components to be installed in that component server, and the
CISA
daemon will look up and load the appropriate dynamic library, invoke
the
home factory method to create the home, and then invoke the home&#8217;s
component
creation method.&nbsp; After all the component instances and homes have
been created and references to them have been obtained, the assembly
manager
will then make all the connections between ports and receptacles,
facets,
and event sources and sinks by invoking connect and subscribe methods
on
the receiving end component.
</p>
<p>QoS-specific metadata like priorities can be configured by a .cad
file
extension called a real-time descriptor (.rtcad) file.&nbsp; The
Assembly
Manager will read the .rtcad file and will parse and associate
real-time
policies with the appropriate component instances.&nbsp;&nbsp; One
implication
of this mechanism is that the Assembly Manager will maintain QoS
meta-data
within its intermediate representation, alongside the conventional CCM
meta-data.
</p>
<p>Furthermore, when the Assembly Manager interacts with the CISA
daemon(s)
on each endsystem, commands to configure particular component and
component
server run-time infrastructure QoS properties are passed from the
Assembly
Manager to the CISA daemon.&nbsp; The ORB (and as a future extension
the
ORB Services) of the endsystem on which the components are installed is
currently configured via the ACE Service Configurator.&nbsp; The CISA
daemon
maps different service configurations (as defined in particular
svc.conf
files) to logical names used in the component assembly descriptors.
</p>
<p>The logical configuration names are encoded within the .cad file as
an extension of the conventional .cad file format using the &#8220;extension&#8221;
element of the existing .cad file XML DTD.&nbsp; The Assembly Manager
passes
a component server creation command, containing a logical configuration
name, which the CISA daemon maps to a particular svc.conf file when it
creates a new component server.&nbsp; The CISA daemon adds a command
line
flag to the execution command line used to spawn the new component
server,
which causes that configuration file to be parsed and applied during
startup
of the component server itself.
</p>
<h3><a name="staticapproach"></a>3. Static Configuration Approach</h3>
In the static configuration approach (<b>Figure 3</b>),
configurations&nbsp;
XML files are translated in a code generation step just before compile
time (managed by the same project/Makefile processes that do the
compilation)
into C++ header and source files that are then compiled and linked with
the main application.
<center>
<p><img src="imgs/ciao-static1.jpg" height="523" width="800"></p>
<p><b>Figure 3. Static Configuration in CIAO</b></p>
</center>
<p>First, one of the generated files is a C++ header file, so that it
can
be included directly by C++ source files.&nbsp; There is no additional
parsing required to import a number of static constants and identifiers
it declares and defines, so that those constants end up being compiled
directly into C++ code.&nbsp; Second, where enumeration of information
is needed, the header file contains simple homogeneous C++ arrays so
that
C++ source code can iterate over those arrays with minimal
overhead.&nbsp;
Third, it declares information so that later information depends on
earlier
information (<b>Figure 4</b>), and the components are directly
configured
within that header file.
</p>
<center>
<p><img src="imgs/ciao-static2.jpg" height="476" width="816"></p>
<p><b>Figure 4. All XML files are parsed offline and stored as
cross-referenced
tables in Static_Assembly_Config.h</b></p>
</center>
<p>The major issues that we addressed in developing a re-factored
version
of the CIAO configuration mechanisms are as follows:
</p>
<p>1. XML parsing is too expensive to be performed during system
initialization,
so that all such parsing has been moved off-line to before
compile-time,
and the resulting information is linked statically into the application
itself.
</p>
<p>2. Each endsystem boots and initializes in a single process address
space, so that any remaining inter-process communication between
daemons
is replaced by direct interactions between objects, or at most between
threads.
</p>
<p>3. Dynamic link libraries are unavailable on VxWorks, so an
alternative
mechanism for obtaining the home factory method entry point is needed.
We gather this information from the XML files and statically generate a
map containing&nbsp; the entry point function names and the entry point
function pointers. This information will be used by the CIAO container
implementation instead of trying to load a dll and then finding the
entry
point in the dll.
</p>
<h4>Moving XML Parsing Earlier</h4>
We first focused on taking the XML parsing stage off-line.&nbsp; Since
the time required to do this by CIAO is currently reasonable as an
off-line
activity, we simply created (<b>Figure 4</b>) a stripped-down version
of
the Assembly Manager (reusing the existing class libraries the Assembly
Manager uses) that after it performs the XML parsing and generation of
its intermediate representation, emits a C++ header file containing
that
intermediate representation.
<h4>Combining Configuration Daemons at Run-Time</h4>
The intermediate representation is included in a configuration engine
(CIAO::Static_Configurator)
that consists of a simple reader for the intermediate representation,
again
derived from the code currently used in the Assembly Manager, which
will
dispatch to the configuration code used by the CISA daemons in the
dynamic
case.&nbsp; The configuration engine will be invoked from the
application&#8217;s
main entry point prior to starting execution of the application itself.
<h4>Eliminating Dynamic Library Loading</h4>
All code will need to be known a priori, and linked statically into the
application.&nbsp; If alternative configurations must be supported
statically,
then those separate configurations can be alternative selections chosen
during the build process.&nbsp; If alternative configurations must be
selected
adaptively at run-time then all the code for each possible
configuration
must be linked in statically, and appropriate mechanisms used to
re-target
a logical name dynamically to each particular configuration (e.g.,
different
configurations for different system modes).
<br>
&nbsp;
<br>
&nbsp;
<br>
<br>
<center>
<p><img src="imgs/ciao-static-vs-dynamic.jpg" height="384" width="735"><br>
<b>Figure 5. CIAO Dynamic vs Static Configuration</b></p>
</center>
<h3>
<a name="status"></a><b>4. Status of CIAO Static Configuration</b></h3>
The initial version of the CIAO static configurator is available under
$CIAO_ROOT/tools/static_configurator.
<p>To run the static configurator,
</p>
<p><b><tt>Static_Assembly_Parser -a &lt;.cad file&gt;</tt></b>
</p>
<p>This will generate three files -
</p>
<p><b><tt>Static_CCM_App.cpp</tt></b> - this file contains the main
program
which instantiates the component server and invokes the static
configuration
engine to create containers, homes, etc.
</p>
<p><b><tt>Static_CCM_App.mpc</tt></b> - this file contains the
necessary
files for building the static application. You have to manually change
this file so as to include files that are not known to the static
configurator.
</p>
<p><b><tt>Static_Assembly_Config.h</tt></b> - this file contains the
C++
intermediate representation of all the information in the .cad, .csd
and
.ssd XML files.
</p>
<p><a name="Example"></a><b>Example</b> - An <a
 href="static_config_example.html">example</a>
run is shown using the <a href="../examples/OEP/BasicSP">BasicSP</a>
scenario.
</p>
<h3><a name="futurework"></a><b>5. Future work</b></h3>
<p>The current implementation does not have support for multiple
component
servers running on multiple processors. Multiprocessor scenario
involves
coordination and synchronization among the component servers running on
different processors. There has to be some kind of a mediator which
determines
that all components are instantiated before connections can be made
among
them.<br>
<br>
&nbsp;
</p>
</body>
</html>
